Patterns are a literary form of software engineering problem-solving discipline. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered in various domains (e.g., software architecture and design, and software development processes and organizations) throughout all of software development. Patterns help create a shared language for communicating insight and experience about the recurring problems and their solutions to promote proven techniques while avoiding “re-inventing the wheel.”
In general, a pattern is the abstraction from a concrete form that keeps recurring in specific non-arbitrary contexts. Each pattern has at least one participant, and each participant plays a role in the pattern. For example, one well-known pattern is an adapter pattern. The adapter pattern solves the recurring problem of allowing classes, which could not otherwise work together, to work together because of incompatible interfaces. As is well known in object-oriented programming, a class is a blueprint used to create an object that has a known identity, state, and behavior. An interface is an abstract class or a Java™ interface that unrelated objects can use to interact with one another. It defines a set of method signatures, but does not implement them. A class that implements the interface agrees to implement all of the methods defined in the interface. The adapter pattern identifies the following as participants in its pattern: a client class, a target interface, an adapter class, and an adaptee class. The roles of these participants in the adapter pattern are described as follows. The client class calls methods associated with the target interface. The adaptee class has a method that a software developer wants the client class to call, but the adaptee's method is not supported by the target interface. Rather than modify the adaptee class to implement the target interface, which may not be an option if the software developer doesn't have the source code for the adaptee class, the software developer manually codes the adapter class participant to implement the target interface such that it calls the adaptee class method. This effectively delegates the method call from the client to the adapter so that the client class can remain independent from the adaptee class. Following the adapter pattern to delegate method calls made through a single interface is especially important where a client class needs to call multiple methods from different classes that are not associated with the single interface.
Software visionaries have published descriptions of a number of patterns in addition to the adapter pattern that solve a variety of common design problems faced by software developers. The published descriptions typically utilize the well-known Unified Modeling Language (UML) to graphically illustrate a pattern. UML is a general-purpose notational language for visualizing, specifying, constructing, and documenting complex object-oriented software systems. UML is more clearly described in the following references, which are incorporated herein by reference: (1) Martin Fowler, UML Distilled Second Edition: Applying the Standard Object Modeling Language, Addison-Wesley (1999); (2) Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide, Addison-Wesley (1998); (3) Peter Coad, Jeff DeLuca, and Eric Lefebvre, Java Modeling in Color with UML Enterprise Components and Process, Prentice Hall (1999); and (4) Peter Coad, Mark Mayfield, and Jonathan Kern, Java Design: Building Better Apps & Applets (2nd Ed.), Prentice Hall (1998).
These literary descriptions and graphical representations identify the following elements of a pattern: a meaningful pattern name that reflects the knowledge and structure of the pattern, the underlying problem solved and the context in which the problem seems to recur, the solution in terms of its participants (e.g., classes and objects) and the relationships between its participants (e.g., static and dynamic rules for composition, inheritance, and instantiation that generally dictate the roles of pattern participants), and the ramifications of applying the pattern (e.g., tradeoffs based on chosen design pattern alternative). It is up to the software developer to manually generate the code corresponding to the pattern and tailor it to the given application or project. This manual generation of a pattern instance suffers from a number of problems: first, it is time-consuming, tedious, and subject to human error; and second, a software developer that is behind in his work will typically skip commenting his code to reflect the use of a common pattern. Hence, other software developers looking to make use of or replace the common pattern cannot easily locate it within the existing code. Conventional software development tools do not address these problems.
Software visionaries have also published techniques to follow for redesigning unwieldy program code prior to or concurrent with adding new functionality that may otherwise add to the complexity of the existing program. These techniques are collectively known as “refactoring.” Refactoring rejuvenates software by improving the structure and performance of existing software without changing the behavior of the software. When refactoring, the software developer typically takes manual, incremental steps to improve the structure of existing code to reduce complexity and avoid prolonged debugging. Such incremental steps may include renaming a method, moving a field from one class to another, or consolidating two similar methods in a superclass. New functionality is generally added after refactoring.
Applying a pattern to existing code combines refactoring with adding new functionality to improve the design of existing code. When applying a pattern, a software developer follows published instructions for generating the known pattern, but manually ascertains what elements of the preexisting code need to be modified or deleted (i.e., refactoring) as well as what elements of the pattern need to be added (i.e., additional functionality) to implement the pattern. Conventional software development tools do not provide support for applying a pattern to existing code. The developer also may deem a portion of the existing code as an undesirable or bad pattern that needs to be redesigned. Faced with the problem of redesigning a bad pattern, the developer typically surveys the existing code to detect any instances of the bad pattern and then manually applies a selected pattern to transform the code for each instance of the bad pattern. Conventional software development tools lack the capability to address these problems.
Finally, software developers often produce reliable and proven program code segments that can be shared between projects and with other developers. Typically, the software developers need to document and advertise the use of this proven program code segment to propagate its continued use. In such cases, the software developer takes the manual steps to copy and paste the proven program code segment into a new project. Conventional software tools lack the ability to assist in automating and publicizing the available patterns/code segments. Thus, there is a need in the art for a tool that avoids the foregoing limitations of conventional software development tools.